There are many situations where client server deployments are used to enable client computers to interact with one or more remote servers over a network. For example, web services, cloud based services and networked applications of many types (such as email, calendar, document processing, games and others. Where applications are networked these typically comprise a graphical user interface or other graphical display and optionally also an audio display.
An existing way to implement such a client server deployment is with a thin client approach. With this approach the server runs the application, and sends each client a video stream of the application which the client displays. The client then sends input events (keyboard, mouse, etc. . . . ) back to the server which processes them. The client merely acts as a remote display and input device without needing any understanding of the specific application being run.
The advantage of this approach is it is relatively simple to implement and is very general purpose (once the client and server are written they can be used to run any application in a networked fashion, even potentially including applications which were not originally designed to be run over a network).
However disadvantages include: sending a video stream to each client is very bandwidth and resource intensive; any network latency will result in a delay between the client providing an input event and the corresponding effect being shown on that client's display, if multiple users are using the application simultaneously it is difficult for them to see different views of the same application. Take for example a networked game application, it might be desirable that each client displays a different area of the map, or each client might have private information only they are supposed to know (for example what cards they are holding in their hand).
Another way to implement a client server deployment is by programming a custom server, client, and protocol for each application. (Instead of using a thin client approach). This way the client can already have many commonly used graphics assets preloaded, and have an understanding of how to fit them together. The protocol rather than just brute force sending the entire display sends just the information which the client needs to reconstruct the display based on its understanding of how the application works. For example for a hypothetical card game application the server can send just a few bytes indicating which cards are on the table, rather than a picture of the entire table, and the client then builds the picture of the table based on its own knowledge of how those cards must be placed. The server can also be programmed to send different information to different clients, so for instance one player cannot see cards held by another. Furthermore by programming a custom client the client can also be programmed to have some understanding of how the application works and hence predict what the server will do in response to certain input events. This allows it to display the result of an input before the server sends that result back, hence reducing perceived network latency.
The disadvantage of this custom client approach is complexity. It involves designing a custom server, client, and protocol for each application. Furthermore the server, client, and protocol must be developed in parallel and if any change is made to one, a corresponding change must be made to the other two. This is error prone and makes rapid prototyping difficult. If the client is also programmed to try and predict what the server will do it is even more complex, as much of the logic code on the server has to be written again on the client to allow it to make those predictions. The client may not have all the information (for example it may not know the cards in other player's hands) so the code on the client often cannot be a straight copy of the code on the server. Furthermore the client may not always predict correctly (for example if another client performs a conflicting action simultaneously), and therefore the client and server must be able to compensate for that incorrect prediction. All of which adds significant expense and risk of bugs compared to just using a thin client approach.
The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known client server interaction processes and deployments.